1. Field of the Invention
This invention relates to access control in a distributed system and, more particularly, to a method and apparatus for controlling server access to a resource in a client/server system.
2. Description of the Related Art
Client/server systems are well known in the field of data processing. In a client/server system, a xe2x80x9cclientxe2x80x9d process issues a request to a xe2x80x9cserverxe2x80x9d process to perform a service for it. In response, the server transmits a reply to the client, notifying it of the results of the service. Often, the client process executes on a personal workstation, while the server process executes on a central xe2x80x9chostxe2x80x9d processor; however, this is not required and the two processes can run on the same machine. The service may be accessing or printing a file, executing an application, or some more specialized service such as providing access control as described below.
The terms xe2x80x9cclientxe2x80x9d and xe2x80x9cserverxe2x80x9d are relative to the service in question. Thus, the same process may be performing a service for a first process while requesting a service (such as access to a resource) from a second. The intermediary process functions as a server relative to the first process and as a client relative to the second.
Server processes of this latter type that request access to resources on behalf of clients present special security problems. For the purpose of gauging their security exposures, servers may be categorized into two general types: trusted servers and untrusted servers. Servers are considered to be xe2x80x9ctrustedxe2x80x9d (or xe2x80x9cauthorizedxe2x80x9d) if they originate from the entity making the determination (usually the vendor of the operating system) or have otherwise been carefully examined so as to provide a high degree of assurance that they are free from malicious code. Servers that cannot be vouched for in sense are regarded as xe2x80x9cuntrustedxe2x80x9d (or xe2x80x9cunauthorizedxe2x80x9d) servers.
Providing security contexts, which are authenticated identities, for client users in client/server applications where the server executes on a host system causes the client to have a host identity whose xe2x80x9cscope of access authorityxe2x80x9d includes resources within the entire host system. If not controlled, this compromises the security and integrity of the entire host system. In the prior art, the only way to control the scope of authority of clients was to make the server code xe2x80x9cauthorizedxe2x80x9d and carefully inspect any such code to make sure that it didn""t misbehave.
In accordance with the present invention, unauthorized servers will be able to issue new security service requests to have security contexts created for their clientsxe2x80x94they could do this before only if they were authorized. With the new service, the security contexts created will be flagged as unauthenticated client security contexts. This is because the host system cannot assume that the xe2x80x9cunauthorizedxe2x80x9d code had not manipulated the request (via trojan-horse code for example) to acquire the authenticated identity of someone other than the true client or to use a valid client""s identity to do something nasty. Later, when any authorization checking request comes to the host system from any resource manager on the host system because the server acting at the request of the client has xe2x80x9casked forxe2x80x9d access to some resource, the host system will require that both the client and the server be authorized to the resource. Thus, the server cannot access any resources outside of its own scope of access authority.
More particularly, the present invention contemplates a method and apparatus for handing requests for access to a resource purportedly on behalf of a client from an untrusted application server in a client/server system, that may be capable of operating as a xe2x80x9croguexe2x80x9d server. Upon receiving a service request from a client, an untrusted application server creates a new thread within its address space for the client and obtains from the security server a client security context, which is anchored to the task control block (TCB) for that thread. The client security context specifies the client and indicates whether the client is an authenticated client or an unauthenticated client.
When the application server makes a request for access to a resource purportedly on behalf of the client, the security server examines the security context created for the requesting thread. If the client security context indicates that the client is an authenticated client, the security server grants access to the resource if the client specified in the client security context is authorized to make the requested access to the resource. If the client security context indicates that the client is an unauthenticated client, the security server grants access to the resource only if both the client specified in the client security context and the application server are authorized to make the requested access to the resource.
With the present invention, the scope of access authority of a client can be limited to only resources that the server itself also has authority to. All other resources within the host system are not accessible by such a client user (while the user is a client user), even though the user may have access authority to other resources when not executing as a client. The servers are no longer required to be authorized or code inspected. Host systems incorporating the present invention thus become much more attractive platforms for the development of server applications.